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TITLE OF INVENTION 
5 FAIL-OVER FILE TRANSFER PROCESS 

ORIGIN OF THE INVENTION 

The invention described herein was made by employees of the 
10 United States Government. The invention may be manufactured and 
used by or for the governmental purposes without the payment of 
royalties thereon or therefor. 

CROSS-REFERENCES TO RELATED APPLICATIONS 

15 This application now formalizes and incorporates herein by 

reference Provisional Application Serial No. 60/235,912, "Standard 
Autonomous File Server (SAFS) " Susan K. Semancik et al . , filed on 
September 28, 2000. Applicant claims the priority date thereof 
under 35 U.S.C. 119 (e) . 

20 

FIELD OF THE INVENTION 

The present invention relates to file transfer systems, and 
more particularly, to a method of handling transfer failure 
occurring while transferring a series, of data files from one 
25 computer to another computer. 

BACKGROUND OF THE INVENTION 

Automated data file transfer systems are utilized in various 
networks and communication systems. The purpose of this automation 
30 is to deliver data files to clients without interfering with 
acquisition of the data. 

The automated data file transfer involves a data transfer 
network wherein a number of computers are interconnected and each 
computer, server or client, is a node in the network wherein data 
35 files are transferred through the network using established 

network protocols. File transfers are initiated in response to a 
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pre-arranged client's request which can be handled only when the 
data transfer resources are available. Each node in the network 
has one or more data transfer facilities which form the network 
interface at the node. These facilities include hardware and 

5 software and the nimiber of active facilities affects network 

congestion and affects the availability of computer resources at 
each of the nodes . 

When transferring files from one computer to another 
computer, e.g. server to client, it is desirable to do so in a 

10 manner which guarantees reliable delivery of the files. 

Unsuccessful transfer attempts unnecessarily add to network 
congestion and may interfere with other transfers. This adds to 
the expense of the network and degrades network performance. 

1 5 SUMMARY OF THE INVENTION 

The present invention provides a fail-over file transfer 
process to handle data file transfer and to avoid unnecessary 
network congestion when the transfer is unsuccessful, enhancing 
reliability in the automated data file transfer system. The fail- 

20 over file transfer process operates in the following manners: 

Prior to the fail-over file transfer operation, a receiver 
may specify backup receiving locations and number of attempts to 
be made before sending a failure notification and/ or attempting 
another backup receiving location. The number of attempts may also 

25 be specified by the sender. If the receiver desires to receive a 
file from a sender at one of the backup receiving locations in 
case of transfer failure, it must specify the locations in advance 
so that the file delivered to the one of backup receiving 
locations can be retrieved when ready. 

30 If it is determined a requested file has not been delivered 

to the receiver, the sender will attempt to send the file to the 
receiver up to the preset niomber of times. If attempting to send 
the file to a receiver up to the preset number of times, and the 
receiver has indicated the availability of other backup receiving 

35 locations, then the file delivery is automatically attempted to 
one of the backup receiving locations up to the preset number of 
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times. Failure of the file transfer to one of the backup 
receiving locations results in a failure notification being sent 
to the receiver, and the receiver may retrieve the file from the 
sender's location when ready. If the file transfer is completed 

5 successfully, a file delivery notification will be sent to the 
receiver. In return, the receiver sends to the sender a receipt 
confirmation notification with a success or error status. Both 
failure notification and file delivery notification may be sent 
via email or World Wide Web (WWW) . 

10 The following is a list of prior-issued patents related to 

file transfer, repeated attempts to transfer files, file transfer 
to backup destinations, and transfer status notification: 
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DESCRIPTION OF DRAWINGS 

FIG. 1 is a diagram of a network wherein Standard Autonomous File 
Server (SAFS) is implemented. 
25 FIG. 2 is a flow chart of fail-over file transfer process. 
FIG. 3 is a diagram of one embodiment of the fail-over file 
transfer process implemented in the SAFS. 

DETAILED DESCRIPTION OF PREFERRED 
30 EMBODIMENT OF THE INVENTION 

Fig. 1 shows an embodiment of the invention using Standard 
Autonomous File Server 10 that provides management of large data 
files without interfering with acquisition of the data. (See 
http: //wwl.wff , nasa.gov/--websafs) It operates as a stand-alone 
35 solution, monitoring itself, and providing automated level of 

fail-over processing to enhance reliability. By using an improved 
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automated file transfer process, the SAFS 10 system provides a 
quicker, more reliable file distribution for customers 3 0 of near 
real-time data than has been realized by previous methods. In 
addition, when overlapping supports occur in multiple projects, 
5 provision is made for file transfer prioritization by bandwidth 
sharing or transfer interruption methods. Web reporting provides 
current status of system availability, file latency, and customer 
file distribution. 

The operational design for network support incorporates 
10 distributed SAFS systems at ground stations on closed networks for 
file acquisition from telemetry processors (TMP) 20, and a 
centralized SAFS 10 at NASA Goddard Space Flight Center (GSFC) on 
open networks for file distribution to project customers. The 
p Central SAFS provides a single point of contact for customers 3 0 
~fl5 and isolates the ground stations from customer interactions. At 
§i each ground station 40, multiple TMP's 20 supporting multiple 

antennas and/or multiple projects, acquire downlinked satellite 
jS data that is processed into files and sent to the ground station 
fij 40 SAFS as shown in Figure 1. Each of these SAFS systems uses 
%,20 commercial off-the-shelf (COTS) software to automatically send 
^f] these files to the central SAFS, where they are made available to 

each project's customers 30. (See http://www.softlinkusa.com) 
□ Customers 30 can receive a file from the SAFS 10 system once 

H they receive a data ready notification (DRN) of its availability. 
25 If they are also using the same COTS product as the SAFS 10 system 
the data file can automatically be sent to them, thereby 
eliminating the delay inherent in the notification and reaction 
processes required for receiving customers. Customers are emailed 
a file delivery notification (FDN) with transfer status upon 
30 completion of the file transfer to them. Both FDN and DRN notices 
contain the file's name, size, and its SAFS location. 

FIG. 2 describes the operation of the fail-over file transfer 
process . 

In response to a pre-arranged request from the receiver, the 
35 sender will attempt to send a requested file to the receiver. (Step 
10) If the file transfer is successful (Step 20) the sender sends 
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to the receiver a file delivery notification that includes name, 
size, origin, and location of the file, for example via email or 
World Wide Web (WWW) . (Step 50) In return, the receiver sends to 
the sender a receipt confirmation notification with a success or 
5 error status. (Step 110) 

If the sender determines that its attempt to transfer the 
file is not successful (Step 20) it will attempt to send the file 
to the receiver up to a preset number of times. (Step 30) The 
number of attempts will be specified, for example, by the receiver 
10 or sender prior to the operation. 

If attempting to send the file to the receiver up to the 
preset number of times fails, the sender sends to the receiver a 
^ failure notification that includes failure status and name, size, 
5 and location of the file so that the receiver can retrieve it when 
£l5 ready, (Step 60 & 130) The failure notification may also be sent 
m via email and WWW. 

nJ Further, if the receiver has specified a backup receiving 

m location prior to the operation, (Step 70) the sender may send the 

file to the backup receiving location. (Step 80) Once the file is 
^20 successfully transferred to the backup receiving location the 
rij sender sends to the receiver a file delivery notification that 
2 includes name, size, and origin of the file via email or World 
U Wide Web (WWW) . (Step 50) In return, the receiver sends to the 

sender a receipt confirmation notification with a success or error 
25 status. (Step 110) 

If the sender determines that its attempt to transfer the 
file to the backup receiving location is not successful (Step 90) 
it will attempt to send the file to the backup receiving location 
up to a preset niomber of times. (Step 100) The number of attempts 
30 will be specified by the receiver or sender prior to the 
operation. 

If attempting to send the file to the backup receiving 
location up to the preset number of times fails, (Step 210) the 
sender sends to the receiver a failure notification that includes 
35 failure status and name, size, and location of the file so that 
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the receiver can retrieve it when ready. (Step 60 & 130) The 
failure notification may also be sent via email and WWW. 

If the receiver has specified other backup receiving . 
locations prior to the operation, (Step 220) the sender may send 
5 the file to one of other backup receiving locations . (Step 230) The 
sequence of selecting one of the other backup receiving locations 
will be predetermined by the receiver. Once the file is 
successfully transferred to one of other backup receiving 
locations the sender sends to the receiver a file delivery 
10 notification that includes name, size, origin, and location of the 
file via email or World Wide Web (WWW) , (Step 50) In return, the 
receiver sends to the sends a receipt confirmation notification 
with a success or error status. (Step 110) 
p If the sender determines that its attempt to transfer the 

'tfl5 file to the one of other backup receiving locations is not 
m successful (Step 240) it will attempt to send the file to the one 

of other backup receiving locations up to a preset number of 
% times, (Step 250) The number of attempts will be specified by the 
Bl receiver or receiver prior to the operation. 

L20 If attempting to send the file to the one of other backup 

receiving locations up to the preset nijimber of times fails, (Step 
260) the sender sends to the receiver a failure notification that 
5 includes failure status and name, size, and location of the file 
H so that the receiver can retrieve it when ready. (Step 60 & 130) 
25 The failure notification may also be sent via email and World Wide 
Web (WWW) . 

The sender continues to perform the steps 22 0 through 2 60 
until the file is successfully transferred to one of backup 
receiving locations . 

30 If the file is not delivered to any of backup receiving 

locations, the sender sends to the receiver a failure notification 
that includes failure status and name, size, and location of the 
file so that the receiver can retrieve it when ready. (Step 60 & 
13 0) The failure notification may also be sent via email and World 

35 Wide Web (WWW) . 
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FIG. 3 describes one embodiment of the fail-over file 
transfer. Upon failure to deliver a file to a receiver 32 0, the 
server 310 sends an FDN email to the receiver 320 with a failure 
status so that the receiver 320 can retrieve the file when ready 

5 during the project-specified retention period. If a file cannot 
be delivered after three attempts, and the receiver 32 0 has 
indicated the availability of secondary backup receiving location 
330, then the file delivery is automatically attempted to the 
secondary backup receiving location 330 at least three times, 

10 Failure of the file transfer to the secondary backup receiving 

location 33 0 results in a failure FDN being sent to the receiver's 
tertiary backup receiving location 340, and the receiver 320 is 
expected to receive the file when ready. 
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